<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><title>Title</title></head><body><div class="cl-preview-section"><h1 id="组件化原理和方案剖析">组件化原理和方案剖析</h1>
</div><div class="cl-preview-section"><p>组件化又叫模块化，即基于可重用的目的，将一个大型软件系统（App）按照关注点分离的方式，拆分成多个独立的组件或模块。每个独立的组件都是一个单独的系统，可以单独维护、升级甚至直接替换，也可以依赖于别的独立组件，只要组件提供的功能不发生变化，就不会影响其他组件和软件系统的整体功能。</p>
</div><div class="cl-preview-section"><p><img src="https://o.devio.org/images/fa/res/Architecture.png" alt="Architecture"></p>
</div><div class="cl-preview-section"><p>从上述的项目架构图中不难看出，组件化的中心思想是将独立的功能进行拆分，而在拆分粒度上，组件化的约束则较为松散。一个独立的组件可以是一个软件包（Package）、页面、UI 控件，甚至可能是封装了一些函数的模块。</p>
</div><div class="cl-preview-section"><p>**组件的粒度可大可小，那我们如何才能做好组件的封装重用呢？哪些代码应该被放到一个组件中？**这里有一些基本原则，包括单一性原则、抽象化原则、稳定性原则和自完备性原则。</p>
</div><div class="cl-preview-section"><p>接下来，我们先看看这些原则具体是什么意思：</p>
</div><div class="cl-preview-section"><h2 id="组件化的原则">组件化的原则</h2>
</div><div class="cl-preview-section"><h3 id="单一性原则">单一性原则</h3>
</div><div class="cl-preview-section"><p>单一性原则指的是，每个组件仅提供一个功能。分而治之是组件化的中心思想，每个组件都有自己固定的职责和清晰的边界，专注地做一件事儿，这样这个组件才能良性发展。</p>
</div><div class="cl-preview-section"><p>一个反例是 Common 或 Util 组件，这类组件往往是因为在开发中出现了定义不明确、归属边界不清晰的代码：“在开发中是有发生一块代码放哪儿好像都不合适，那就放 Common（Util）吧”。久而久之，这类组件就将变得非常的臃肿和难以维护。</p>
</div><div class="cl-preview-section"><blockquote>
<p>因此，当你遇到不知道该放哪儿的代码时，就需要重新思考组件的设计和职责了。</p>
</blockquote>
</div><div class="cl-preview-section"><h3 id="抽象化原则">抽象化原则</h3>
</div><div class="cl-preview-section"><p>抽象化原则指的是，组件提供的功能抽象应该尽量稳定，具有高复用度。而稳定的直观表现就是对外暴露的接口很少发生变化，要做到这一点，需要我们提升对功能的抽象总结能力，在组件封装时做好功能抽象和接口设计，将所有可能发生变化的因子都在组件内部做好适配，不要暴露给它的调用方。</p>
</div><div class="cl-preview-section"><h3 id="稳定性原则">稳定性原则</h3>
</div><div class="cl-preview-section"><p>稳定性原则指的是，不要让稳定的组件依赖不稳定的组件，假如：A组件依赖了B组件，如果A组件很稳定，但是B组件经常变化，那么A组件就会跟着B的变化而经常适配从而变得不稳定了。</p>
</div><div class="cl-preview-section"><blockquote>
<p>此时我们可以考虑将B组件中存在的不变的且A组件不可或缺的代码拆出来单独做成一个新的组件C。</p>
</blockquote>
</div><div class="cl-preview-section"><h3 id="自完备性">自完备性</h3>
</div><div class="cl-preview-section"><p>自完备性，即组件需要尽可能地做到自给自足，尽量减少对其他底层组件的依赖，达到代码可复用的目的。比如，A组件只是依赖某个大B组件中的某个方法，这时更好的处理方法是，剥离掉A组件对B组件的依赖，直接把这个方法拷贝到A组件中。这样一来A组件就能够更好地应对后续的外部变更了。</p>
</div><div class="cl-preview-section"><h2 id="组件化实施步骤">组件化实施步骤</h2>
</div><div class="cl-preview-section"><p>在理解了组件化的基本原则之后，我们再来看看组件化的具体实施步骤，即剥离基础功能、抽象业务模块和最小化服务能力。</p>
</div><div class="cl-preview-section"><p>首先，我们需要剥离项目中与业务无关的基础功能，比如：网络操作、本地缓存、第三方库封装、UI 组件等，将它们封装为独立的基础库然后，我们在项目里用<code>pub</code>进行管理。</p>
</div><div class="cl-preview-section"><blockquote>
<p>如果是第三方库，考虑到后续的维护适配成本，我们最好再封装一层，使项目不直接依赖外部代码，方便后续更新或替换，比如：我们基于<code>chewie</code>封装了<code>hi_videoview</code>，基于<code>fluter_swipter</code>封装了<code>hi_banner</code>等。</p>
</blockquote>
</div><div class="cl-preview-section"><p>基础功能已经封装成了定义更清晰的组件，接下来我们就可以按照业务维度进行拆分了，比如：登录模块、首页模块、详情模块、排行榜模块等。拆分的粒度可以先粗后细，只要能将大体划分清晰的业务组件进行拆分，后续就可以通过分布迭代、局部微调，最终实现整个业务项目的组件化。</p>
</div><div class="cl-preview-section"><p>在业务组件和基础组件都完成拆分封装后，应用的组件化架构就基本成型了，最后就可以按照刚才上文中的4个原则，去修正各个组件向下的依赖，以及最小化对外暴露的能力了。</p>
</div> <h1 style="color: red">认准一手，获取完整资料<br>QQ3195303913<br>微信wxywd8<br><br><br><br>高价回收正版课</h1></body></html>